-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a new flow to request for accountInfo by name from a particular host #94
base: master
Are you sure you want to change the base?
Add a new flow to request for accountInfo by name from a particular host #94
Conversation
@InitiatingFlow | ||
class RequestAccountInfoByName(private val accountName: String, val host: Party) : FlowLogic<AccountInfo?>() { | ||
@Suspendable | ||
override fun call(): AccountInfo? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ourIdentity == host
, then just fetch the account from the current node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comments.
This flow is specifically to request accountInfo from another node and not from the caller's local node itself. The assumption here is that the caller is aware that an account with name "charlie" exists on host node "Alice". (obviously the caller will try to search for account with name "Charlie" on its local vault first)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my humble opinion, you cannot assume how your flow will be used; your code should take care of all cases.
For instance, in the RequestKeyForAccountFlow
(which comes with the library):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the design of this flow is kept in consistent with the design of RequestAccountInfoFlow (here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see; now I'm curious why they did it that way 🙂
*/ | ||
class RequestAccountInfoByNameFlow(private val accountName: String, val host: FlowSession) : FlowLogic<AccountInfo?>() { | ||
@Suspendable | ||
override fun call(): AccountInfo? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If host.counterParty == ourIdentity
, then just fetch the account from the current node.
Hmmm - what is to stop a "malicious" node from spamming lots of requests by name. This could potentially lead to situations where data is leaked. The purpose of using the UUID was to make it impossible to guess names. |
I'm not sure we should add this as a standard feature as it potentially leaks info about account holders. I think it's OK to look-up account holders by hash / UUID but by name is probably too much. Imagine a node being spammed with requests to figure out if some person/entity has an account there. I guess this depends actually how the account name property is used but we cannot assume it won't be a company or person name as the property is just a |
Hmm that makes sense.. Just thinking out loud here slightly on a diff context- a node can be even spammed and attacked with requests to provide new public key(s) for an account by invoking |
As a CorDapp developer I would like to use a built-in flow from the library that can help me to fetch account details from a particular host by name and not by UUID.
If that particular host doesn't have an account created then it should return null.
Use-case: In some situations a node might have obtained
account name
(may be from front-end app or some offline channel) and wishes to fetch account Info details by passing that name to the host. If the account exists on that host then it should return the accountInfo else return null. e.g. a company creates account of its employee by using SSN/NIN or employee_id as account name and another company can request for accountInfo by passing account name for background-check.